Computer networks may be used to communicate data between a sender and one or more receivers. The data, e.g., in the form of one or more packets, traverses paths that comprise network elements, such as nodes and links, between the sender and the receiver, generally along a computed shortest path between the sender and receiver based on one or more path metrics (e.g., cost). Some computer networks may remove network elements from path computation that do not meet certain criteria (e.g., constraints), such that no network element along the computed path fails to meet the criteria.
Often, customers may desire configuration of a private network to protect the privacy and security of their data within the private network. Sometimes, however, a customer may have multiple network locations that are distanced from one another in such a way that to maintain a private network, substantial costs (e.g., monetary) may be required. A Virtual Private Network (VPN) is a private data network that utilizes public networks to enable communication between distanced members of the same VPN (e.g., the customer's private network). For instance, privacy may be maintained between customer networks that span the public networks (e.g., a service provider network) through the use of various tunneling protocols and security features, as will be understood by those skilled in the art. Illustratively, a source device (sender) in a one customer network may wish to send data to a destination device (receiver) in another customer network of the same VPN across the service provider (e.g., public) network. Accordingly, the source transmits the data (traffic) to a customer edge device (CE) of the source device's customer network, which is in communication with an ingress provider edge device (PE) of the provider network. The service provider network (e.g., a “core”) transmits the traffic to an egress PE interconnected with a CE of the customer network that has the destination device, and that CE forwards the traffic toward the destination device.
Some customers desire path diversity for site-to-site (customer-to-customer) traffic, i.e., where two or more paths between the customer networks exist that do not share network elements (nodes or links). For instance, path diversity may be driven by customers that require dual attachment to the service provider's core network for critical application needs (such as, e.g., financial institutions). Typically, such customers utilize multiple (e.g., dual) connections via diverse links connected to diverse PEs (which may or may not be co-located on a same physical device). Path diversity may be used to ensure that in the event of a single path failure (e.g., an element along the path), another diverse path is able to carry the flow of traffic between the customer networks. Path diversity may also be used for load-balancing traffic (e.g., also so that a failure along one path does not effect both paths) and other reasons as will be understood by those skilled in the art.
One problem associated with path diversity for customers that are “multi-homed” to the service provider network (i.e., have multiple connections to the provider network) is that such diversity cannot be guaranteed simply through local customer network interconnection with multiple diverse PEs. That is, in order to send different traffic flows to the diverse PEs (ingress PEs) for one or more destination address prefixes, the ingress PEs typically forward the traffic into the provider network core; however, there is no guarantee inside the core that the paths remain diverse. In other words, the paths inside the service provider network, although originating at diverse ingress PEs, may share a resource (network element) or may converge to a same egress PE, the failure of either of which adversely impacts both flows.